home *** CD-ROM | disk | FTP | other *** search
- From: bousch@suntopo.matups.fr (Thierry Bousch)
- Subject: Re: two bugs fixed in ramfs 1.4
- Date: Mon, 29 Nov 1993 23:22:54 +0100 (MET)
- Vincent.Pomey@linn.fidonet.org (Vincent Pomey)
- In-Reply-To: <m0p403e-0000czC@sdf.lonestar.org> from "Evan Langlois" at Nov 28, 93 10:17:00 pm
-
- Hello Evan,
-
- > ======================== quote =======================
- > You should apply the following patch to ramfs.c to upgrade it from
- > version 1.4 to version 1.5. It fixes these two bugs.
- > =======================================================
- >
- > I believe there is another bug. STZIP Fseek's to the end of the
- > file to read the header information at the end. STZIP is not able
- > to read the header information from any file on RAM FS. I believe
- > its a problem of RAMFS.
-
- increasing the debug level in MiNT reveals that stzip issues a
-
- Fseek(-2048,2) on handle 6
-
- which should hopefully put the pointer 2048 bytes before the end of the
- file. The problem is of course: should the offset really be negative? I
- have two books about Gemdos which give two different answers to this
- simple question -- probably Murphy's law.
-
- Most of the device drivers existing for MiNT (procfs.c, shmfs.c,
- clockdev.c) assume that Fseek(offset,handle,2) will put the pointer
- "offset" bytes _before_ the end of the file. Therefore, "offset" should
- be positive. Ramfs also follows this convention. Minixfs probably
- follows the opposite convention, since it works with stzip.
-
- [ We could make the program more bomb-proof by considering only the
- absolute magnitude of "offset"; but in ramfs you should also be able to
- seek past the end of a file, so it's not desirable. ]
-
- Thierry.
-